1. Field of the Invention
The present invention pertains to program compilation and, more particularly, to speculative compilation of a program.
2. Description of the Related Art
There typically is a sharp distinction between the code with which people program a computer and the code that the computer actually executes. Computers perform their programmed tasks by executing what is known as “object code.” Object code is a series of 1's and 0's that the computer's processor reads and interprets to perform its programmed tasks. However, actually programming in object code is exceedingly difficult, tedious, and time-consuming for a programmer. Programmers therefore rarely program in “object code.” Once a program has been designed, a programmer will usually code the program in “source code.” Source code is a high level language such as C, C++, Objective C, FORTRAN, ADA, PASCAL, etc. that is easier for people to read.
“Compilation,” in the context of computer programming, is the process by which a computer translates source code to object code. Compilation is performed by a software tool called a “compiler” executed by the computer for this purpose. Compiler design and compilation involve many considerations and are sufficiently complex that whole books have been written on the topic. See, e.g., Alfred V. Aho, et al., Compilers—Principles, Techniques and Tools (Addison-Wesley Pub. Co. 1986) (ISBN 0-201-10088-6). However, some generalizations may be drawn.
In the classic scenario, the programmer codes the program in source code using a “text editor,” another software tool. When the programmer finishes coding the program, the programmer saves the program and invokes a compiler. More particularly, a programmer writes and edits one or more source code program files and then initiates a “build” to compile these source code files. The build process may be initiated by the programmer in various ways, including through a user interface gesture (e.g., clicking on a “build” button) or by invoking a command, such as make or jam, from a command line.
Once the compiler compiles the source code into object code, the compiled object code can then be executed by the computer. In the program's development phase, the source code may be debugged by editing the program in the text editor and then compiling (or, recompiling) the edited source code. This process may be iterated many times, depending on the complexity of the program. Each time, the compiler is invoked on the whole program. However, under the conventional approach, no compilation occurs until the user expressly initiates a build. As such, much of the “idle time” during which the user is proof-reading or editing source code goes unused.
Consider the example shown in FIG. 1. FIG. 1 illustrates a source code program 100 comprised of multiple files. The source code program 100 is written in C, and is presented in pseudo-code. The source code program 100 comprises a source file 102 name “a.c” and several header files 104, 106, 108 named “a.h,” “b.h,” and “c.h,” respectively. The header files 104-108 are defined as part of the source code program 100 by the “#include” statements 110, 112, 114, in accordance with the programming principles for C. The header files 104-108 may contain declarations or definitions of data types and variable declarations and some inline code declarations used by the source file 102.
In accord with conventional practice, the programmer fully enters all the source code 100 through the end 116 thereof. The programmer then invokes a compiler, not shown in FIG. 1. The compiler includes a “file reader” that starts reading the source file 102, diverting to the header files 104-108 as it comes across the respective “#include” statements 110-114. The compiler reads through each header file 104-108 to its end, and returns to the source file 102 after finishing the respective header files 104-108. The compiler continues reading the source file 102, diverting to header files 104-108 when it encounters the “#include” statements 110-114, respectively, until it reaches the end of 116 of the source file 102. This reading of the source file 102 is but one part of the compilation process.
On average, the majority of time spent in any given compilation of a C-type program is spent in reading the header files of the source code program. It is not unusual for a compiler to process orders of magnitude more data in header files than it does in source files. However, the code in the header files rarely, if ever, changes during the editing sessions of the source files. Thus, as a general rule, the header files take less time to develop than do the source files, but take much longer to process for compilation.
Some attempts have been made to combine the steps of coding the source code and compiling it into object code. Typically, these attempts are in the form of “interpreted languages.” Apple's APPLESCRIPT and Microsoft's VISUAL BASIC are two tools that attempt to compile the source code as the programmer codes the program. Both of these tools combine the function of the text editor and the compiler. In theory, this accelerates the development process since the compilation does not have to wait for all the source code to be entered.
Users of these kinds of tools report great satisfaction because the development process is relatively rapid. However, these tools suffer from disadvantages. One disadvantage is loss of efficiency. One important aspect of most compiler designs is code “optimization.” See Aho et al., supra, at pp. 585-718. Code optimization typically involves modifying some portions of an intermediate representation of the source code so that the resulting object code runs more efficiently. Most optimizations require analysis of, and modifications to, instructions that may be separated by any number of lines of source code. By handling each line of code one line at a time, these types of tools lose the efficiencies that might otherwise be obtained through optimization. These tools therefore are used for smaller kinds of programs and those in which speed is not of prime importance, and generally are not used to create, for example, large desktop applications.
Some attempts have therefore been made to develop text editor-compiler tools dedicated to C-type languages commonly used to create desktop applications. C-type languages include, e.g., C, C++, and Objective C. Exemplary of this type of tool is SABER-C. These types of tools generally performed well in implementing a rapid development phase compiler and a slower production phase compiler. However, these tools failed to implement the identical production compiler semantics of their competitors and lost popularity.
An alternative approach employs “pre-compiled” header files with C-type languages. In this approach, some header files that may be frequently used are pre-compiled and stored. Then, when it comes time to compile the program, the header files are already compiled, thereby reducing compile time for the program as a whole. Pre-compiled header files, however, take a relatively large amount of storage. This mitigates against their frequent use, particularly with arbitrary sets of files with non-uniform initial sequences of preprocessing directives.
The present invention is directed to resolving, or at least reducing, one or all of the problems mentioned above.